Another thing which may have fallen through the cracks: should BlockRngCore be exported from rand? Possibly not necessary.

I don't know. I think BlockRngCore may some day play a role with better SIMD support. But for now it is mostly an implementation detail of RNG's. I would a little before re-exporting it.

The only real reason is that ReseedingRng requires BlockRngCore.

Good point. Shall I add it to this PR?

Looks ready for merge to me

Is the point of EntropyRng that it can use woefully insecure things when nothing secure is available?

😄 Actually quite the opposite.

It just builds on the idea that OsRng is the best choice of secure external randomness, but sometimes it is not available (and that is not only theoretical). EntropyRng falls back to the next best choice of secure randomness. This prevents user code from panicking, or from using really insecure workarounds like using the clock.

Using the clock directly (like I tried doing before this), that is. JitterRng flat out gives up if it doesn't have enough precision to gather secure entropy.

I think an entropy based CSPRNG needs to know when it has enough randomness and refuse to give out random numbers if it does not. We've no error path so this mean it needs to panic. Is that what happens?

JitterRng is not a CSPRNG, but an entropy collector. It uses variances in the time the CPU takes to execute instructions, and variations in timings for memory access. It does a self-test first to see if the timer is granular enough, and the variance is enough to use.

Apologizes but I ignored the whole JitterRng things under the impression that ThreadRng cannot be a CSPRNG anyways and hence not CryptoRng. We've some argument that a CSPRNG can be based on JitterRng?

You can read all about it on the author's page (This is just a Rust implementation of his library) www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html

A CSPRNG only needs enough entropy for seeding, after that it's independent of the entropy source (unless you want to reseed).

JitterRng supplies entropy securely (given a good CPU timer) but is SLOW, i.e. it blocks while gathering entropy.

I'll read it, thanks! I also finally noticed the panic when entropy sources fail, which makes sense. lol

I'd suggest adding this method, both so that users know how to test if an EntropyRng is ready, and to help test that try_fill_bytes works right with a zero length destination.

impl EntropyRng {
    fn is_ready(&mut self) -> bool {
        self.try_fill_bytes(&mut [0u8; 0]).is_ok()
    }
}

I do not understand why EntropySource::None exists. I'd think EntropyRng::new() should either use OsRng if it works or launch JitterRng sooner, so that JitterRng launches sooner. I'll maybe figure this out form reading about JitterRng though.

@burdges Thanks for giving it such close attention 😄.

The idea to use None instead of doing a first try in new() came from #235 (comment). This way it is possible to do things like X::from_rng(EntropySource::new()).

EntropyRng has no concept of being ready / not ready. For that OsRng would ideally poll on /dev/random, and JitterRng would have to live in its own thread. So I am not sure it adds much.

A test for fill_bytes with a zero length destinations is something to keep in mind!